Компания VMware обновила пакет драйверов Community NVMe Driver for ESXi до версии 1.1 на сайте проекта VMware Labs. Эти драйверы были выпущены в начале года, а сейчас вышло их обновление с поддержкой VMware ESXi 7.0.

Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.

Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:

Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).

Драйверы поставляются в виде VIB-пакета, установить который можно командой:

Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a. Также мы рассказывали о том, как зайти в консоль вспомогательных виртуальных машин VM Service.

Пару недель назад Cormac Hogan выпустил интересное видео для разработчиков и администраторов, в котором показывается, как можно создавать виртуальные машины на базе vSphere with Tanzu с помощью YAML-манифеста для пользовательских данных и ВМ:

Ну и, конечно же, рекомендуем отличную статью "A first look at vSphere VM Service" от автора видео.

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

Компания VMware заявила о доступности решения VMware NSX Advanced Firewall for VMware Cloud on AWS, предназначенного для защиты сетевых соединений организаций, использующий публичное облако VMware Cloud на базе инфраструктуры AWS SDDC (software-defined data center). С помощью этого фаервола администраторы смогут контролировать все коммуникации на уровне 7, используя DPI-техники анализа пакетов на всех виртуальных сетевых адаптерах vNICS виртуальных машин на хостах ESXi виртуального датацентра SDDC.

Используя NSX Advanced Firewall for VMConAWS, вы получите следующие возможности:

• Обнаружение попыток использования эксплоитов и уязвимостей в вашей инфраструктуре
• Защита от уязвимостей на базе гранулярных политик безопасности, работающих на уровне приложений
• Уменьшение поверхности атаки для ваших рабочих нагрузкой за счет регулирования только разрешенного трафика приложений в вашем датацентре
• Бесшовный анализ всего трафика датацентра без единой точки анализа, которая могла бы вызвать падение сетевой производительности
• Возможности для обеспечения соответствия отраслевым стандартам (compliance)

NSX Advanced Firewall можно купить как аддон к вашей инфраструктуре VMware Cloud on AWS. Подробнее об этом фаерволе вы можете прочитать в блоге VMware.

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

В случае с отказом Primary хоста все немного дольше и сложнее, так как кластеру нужно определиться с новым Primary узлом и восстановить/перенастроить себя. Тут происходит следующее:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

Надо помнить, что это все времена начала процессов, но не их завершения. Например, если процесс восстановления начинается через 15 секунд, то нужно время, чтобы найти место для виртуальной машины на новом хосте и запустить ее там – а вот это время рассчитать невозможно.

Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.

Дункан Эппинг показал на примере виртуального коммутатора vSwitch, как можно работать с configstore и хранящимися там настройками. Например, вам требуется сменить имя виртуального коммутатора. Вы можете посмотреть его текущие сетевые настройки командой:

configstorecli config current get -c esx -g network_vss -k switches

Ну а экспортировать эти настройки в JSON-файл можно командой:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:

Потом получившийся файл нужно обратно импортировать в configstore:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

После этого вы увидите изменения в vSphere Client:

Также Дункан записал видео, в котором показан этот процесс:

На сайте проекта VMware Labs вышло очередное обновление - VMware ESXi Arm Edition версии 1.4. Напомним, что эта специальная версия версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О версии 1.3 мы писали в начале апреля вот тут.

Давайте посмотрим, что нового в июньской версии VMware ESXi ARM Edition 1.4:

• Улучшенная технология виртуализации PMU (Performance Monitoring Unit)
• Исправлены проблемы с виртуальным устройством AHCI для некоторых ОС ACPI
• Улучшена работа с обработкой времени
• Экспериментальная поддержка NVIDIA Tegra Xavier AGX и NVIDIA Tegra Xavier NX (PCIe, USB, NVMe, SATA). Это что-то типа вот такой штуки:

• Экспериментальная поддержка серверов 2P Ampere на базе Altra. Это вот такие штуки:

• Увеличенная производительность виртуальных машин для мультисокетных серверов на базе ARM
• Исправлены проблемы с виртуальным NVMe в UEFI для некоторых ОС
• Улучшена виртуализация контроллера прерываний
• Улучшена общая производительность гипервизора и техник виртуализации в целом
• Улучшена совместимость с ядрами Linux для новых ОС
• Исправлены проблемы стабильности USB-устройств, особенно для сетевых адаптеров на базе RTL8153 для платформ Raspberry Pi и Tegra Xavier
• Обновлена документация для ESXi-Arm Fling, Raspberry Pi, Ampere Altra, NVIDIA Xavier AGX и NVIDIA Xavier NX (опции доступны в комбобоксе при скачивании продукта)

Загрузить VMware ESXi ARM Edition 1.4 и документацию можно по этой ссылке.

На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

Весной этого года мы писали о двух критических ошибках безопасности в сервисах VMware Carbon Black и VMware vCenter - тут и тут, соответственно. В свое время для них были выпущены патчи, закрывающие эти уязвимости. Но, надо сказать, что это далеко не единственные критические моменты в инфраструктуре безопасности vCenter - на днях VMware опубликовала патчи к VMSA-2021-0010 (сообщения CVE-2021-21985 и CVE-2021-21986).

Суть уязвимости заключается в том, что в плагине Virtual SAN Health Check есть дыра в процедуре валидации ввода данных, которая позволяет злоумышленнику получить доступ к удаленному исполнению кода через vSphere Client. CVSSv3 base score этой уязвимости максимальный - 9.8, поэтому нужно обновлять серверы vCenter прямо сейчас.

Если вы не используете VMware vSAN, у вас все равно эта дырка есть, так как плагин vSAN идет вместе с установкой vCenter по умолчанию. Затронуты, кстати, vCenter версий 6.5, 6.7 и 7.0 и их обновления, то есть все самые актуальные на текущий момент. Компания VMware создала по данной уязвимости специальный FAQ.

Если вы не пользователь vSAN, то плагин вы можете просто отключить, но вот если вы используете vSAN для хралищ на базе серверов ESXi, то отключение плагина приведет к невозможности пользоваться консолью управления vSAN.

Также по данной уязвимости на VMware Communities есть специальный трэд.

Итак, теперь, собственно, какие патчи вам надо накатить (полное описание находится здесь):

• Для VMware vCenter 7.0 накатываем vCenter 7.0 Update 2b (вот тут)
• Для vCenrer 6.7 накатываем vCenter 6.7 Update 3n (вот тут)
• Для vCenrer 6.5 накатываем vCenter 6.5 Update 3p (вот тут)

VMware настойчиво рекомендует сделать обновление прямо сейчас, чтобы злоумышленники и всякое ransomware не добавили вам проблем, например, перед летним отпуском:)

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

На сайте проекта VMware Labs обновился Community Networking Driver for ESXi до версии 1.2. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.

С момента того, как мы впервые писали об этом пакете драйверов, вышли их версии 1.1 и 1.2 - давайте посмотрим, что в них появилось нового:

• Поддержка больших пакетов Jumbo Frames (размер MTU до 9000)
• Поддержка механизма Wake-on-LAN (WOL) для устройств Intel i225 NIC
• Исправлена проблема для карточек Intel vPro, которая могла приводить к "розовому экрану смерти" (PSOD) на ESXi

Драйверы можно установить для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:

Установить драйвер можно с помощью команды:

esxcli software vib install -d /path/to/the offline bundle zip

После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.

Скачать Community Networking Driver for ESXi 1.2 можно по этой ссылке.

Когда вышло обновление VMware vSphere 7 Update 2, мы рассказывали о новых оптимизациях для процессоров AMD EPYC, которые были сделаны в платформе виртуализации на базе гипервизора ESXi. Реализация поддержки новых функций CPU идет в соответствии с развитием технологий аппаратной виртуализации AMD, которую VMware поддерживает наравне с таковой от Intel.

Недавно VMware выпустила отдельный документ "Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors", где рассказано, какие были сделаны оптимизации, и как именно они влияют на увеличение производительности:

В документе есть много интересных тестов (большинство из них сделано с помощью утилиты VMmark3), приведем ниже результаты некоторых из них:

• Увеличение производительности одной ВМ для БД Microsoft SQL Server под нагрузкой HammerDB (тут и далее нормировано к показателям vSphere 7 Update 1):

• Несколько виртуальных машин с 8 vCPU на борту и нагрузкой HammerDB - производительность при увеличении числа виртуальных машин на хосте:

Использование базы данных CockroachDB на 6-узловом кластере, прирост производительности до 50%:

Тестирование кластера Kubernetes c узлами по 64 воркера с помощью бенчмарка Weathervane (на 16 инстансах приложений прирост производительности - более 40%):

В общем, документ очень интересный - посмотрите.

Не так давно мы писали о механизме VMware vSAN Enhanced Durability, который позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:

При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?

Ответ тут прост - этот компонент будет создаваться на других хостах, даже если он выполняет функции Witness (но, конечно же, он будет создан на хосте этой площадки):

Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:

На сайте проекта VMware Labs появилась новая версия утилиты Virtual Machine Compute Optimizer 3.0, о которой в последний раз мы писали летом 2019 года. С тех пор вышло несколько обновлений этого средства. Напомним, что VMCO - это PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

В третьей версии сценария появился рабочий процесс установки/апгрейда всех необходимых модулей - VMCO и PowerCLI. Теперь это единый сценарий, в котором есть мастер, проходящий по всем шагам установки модулей, соединения с vCenter и экспорта результатов.

Также в последних версиях была добавлена опция -simple, которая позволяет отобразить только информацию о виртуальных машинах (без серверов vCenter, кластеров и хостов ESXi), обновлена документация и исправлено много ошибок.

Скачивайте Virtual Machine Compute Optimizer 3.0 и выясняйте, правильно ли у вас настроены vCPU и Memory для виртуальных машин. Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри.

Большинство маководов знают, что с 2020 года компания Apple делает ноутбуки MacBook с процессорами M1 на базе архитектуры ARM в рамках серии Apple Silicon. Те, кто нас читают регулярно, знают, что компания VMware уже некоторое время делает эксперименты по виртуализации на базе архитектуры ARM и даже имеет свой серверный продукт ESXi ARM Edition. Многие у нас в комментариях спрашивали - а зачем, собственно, это продукт нужен? Один из ответов - это разрабатываемая сейчас платформа VMware Fusion для Apple MacBook с процессорами M1.

Скорее всего, вы уже знаете, что ноутбуки на базе M1 показывают чудеса эффективности - низкое энергопотребление, высокая производительность, что в итоге дает время работы до 20 часов без зарядки, что практически недостижимо сейчас на базе стандартной x86/64-архитектуры.

Поэтому очевидно, что VMware включилась в этот поток и еще прошлой осенью анонсировала разработку платформы Fusion, которая уже ведется вопреки всем сложностям, связанным с разделением внутренних команд разработки из-за коронавируса.

Как описано вот в этой статье, на данный момент по VMware Fusion для ARM ситуация следующая:

• Tech Preview платформы VMware Fusion для macOS на базе Apple Silicon будет готово уже в этом году.
• VMware не планирует поддерживать виртуальные машины на базе x86 в этой версии Fusion.
• С Windows 10 ARM, которая сейчас находится в статусе Insider Preview, есть лицензионные сложности.
• Поэтому в приоритете поддержка Linux-систем, на которые брошены основные силы разработки.
• Виртуальные машины macOS тоже пока не планируются, так как требуется совместная работа команд VMware и Apple над поддержкой этой технологии, а с этим также есть трудности.

Прежде всего, надо сказать, что внутренняя версия у разработчиков для гостевых ОС Linux уже работает. В статье по ссылке выше рассказано о том, как на ноутбуке (M1 MacBook Air 8 CPU + 8GPU, 16GB RAM) без проблем работают 7 виртуальных машин, а один из разработчиков говорит, что такой производительности он не видел за свои 12 лет работы в VMware.

Если с Linux все более-менее понятно, то с Windows ситуация неясна. Пока лицензия на Windows 10 Insider Preview для ARM содержит следующее:

To install Windows 10 Insider Preview Builds, you must be running a licensed version of Windows 10 on your device.

То есть на данный момент Microsoft не дала зеленый свет сторонним разработчикам решений для виртуализации, и есть несколько дискуссий на эту тему (раз+два). Также Microsoft пока только сообщает вот что:

With Windows 10 on ARM Insider Preview builds, you can create 64-bit ARM (ARM64) VMs in Hyper-V on Windows 10 ARM-based PCs. Creating ARM64 VMs is not supported on x64 hardware.

ARM64 VMs are only supported on devices that meet the pre-requisites:

• Windows 10 ARM-based PCs with a Microsoft SQ1, Microsoft SQ2, Qualcomm Snapdragon 8cx, or Qualcomm Snapdragon 850 processor
• Windows 10 Pro or Enterprise, build 19559 or newer
• Hyper-V enabled (instructions)

Тем не менее, VMware общается с Microsoft по этому вопросу, поэтому в итоге, скорее всего, какое-то продуктивное соглашение здесь, все-таки, будет.

Что касается отсутствия поддержки x86 виртуальных машин, то тут суть такая - их поддержка вызовет определенные технические сложности и, скорее всего, проблемы с падением производительности из-за эмуляции. Ну а сама Microsoft планирует сделать поддержку x86 приложений в своей ОС для ARM, поэтому лучше всего будет использовать механизм Microsoft, так как он более нативен, поскольку будет реализован на уровне слоя эмуляции приложений, а не всей виртуальной машины в целом.

В общем, до конца года ожидаем техническое превью VMware Fusion для макбуков на базе M1.

Многие из вас, наверняка, знакомы с инфраструктурой публичного облака VMware Cloud on AWS, которая была анонсирована еще летом 2017 года. Это все та же платформа VMware vSphere, все те же серверы VMware ESXi, но стоят они физически в датацентрах Amazon. Все это управляется совершенно нативно для инфраструктуры vSphere, туда же включаются и решение...

Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

• Supervisor Cluster
  • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
  • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
• Tanzu Kubernetes Grid Service for vSphere
  • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
  • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
  • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-7.0U2a-17867351-standard \

-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.

Некоторое время назад мы опубликовали статью о протоколах NTP и PTP, которые отвечают за работу служб точного времени для хоста ESXi и виртуальных машин.

Оказывается, в весеннем обновлении VMware vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).

VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.

Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.

API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.

vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.

Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.

Ну и в завершение надо отметить, что vmwTimeProvider не выбран по умолчанию при установке, так как он не нужен системам без специальных требований к службам времени.

На сайте проекта VMware Labs вышло обновление VMware ESXi Arm Edition 1.3. Напомним, что эта версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлом релизе этой платформы мы писали вот тут.

Давайте посмотрим, что нового в ESXi для ARM:

• Улучшенная аппаратная совместимость (множество исправлений ошибок и улучшений по поддержке железа).
• Добавлена экспериментальная поддержка архитектуры Ampere Altra (только для односокетных систем (подробнее тут).
• Поддержка ACPI для виртуальных машин.
• Поддержка загрузки через NVMe и PVSCSI в EFI.
• Добавлен воркэраунд для загрузки с ISO для некоторых ARM-серверов.
• Пофикшена проблема с падением современных ОС при работе на системах на базе Neoverse N1.
• Улучшен механизм виртуализации контроллера прерываний для гостевых ОС.
• Улучшены средства работы с виртуальными PMU.
• Улучена поддержка big endian.

Скачать установочный образ VMware ESXi Arm Edition 1.3 можно по этой ссылке. Помните, что апгрейд с предыдущей версии не поддерживается - надо устанавливать заново.

Небольшое обзорное видео установки ESXi Arm Edition:

Многие администраторы VMware vSphere знают, что для серверов ESXi установлен лимит одновременных миграций vMotion (входящих и исходящих) на один хост = 8 штук. Многие интересуются, а почему именно восемь? Ведь если бы увеличить это число, то виртуальные машины с хоста смогут быстрее эвакуироваться во время проведения планового обслуживания и обновления хостов при их переводе в режим обслуживания (maintenance mode).

Для разъяснения этого VMware написала интересную статью, где рассматриваются результаты тестирования миграций vMotion виртуальных машин при разных значениях параметра, ограничивающего число одновременных миграций.

Лимит на vMotion установлен со стороны сервера vCenter. Он считает ограничения следующим образом. Если на хосте 2 физических сетевых карты 40GbE NIC, выделенных под vMotion, то он считает каждую из них как емкость из 8 слотов с точки зрения миграций, а совокупная емкость хоста равна 16 слотам, из которых 2 тратится на каждую операцию vMotion:

В VMware сделали тестирование производительности одновременных миграций vMotion на хостах ESXi в рамках тестового стенда (он описан в статье), где число Concurrent vMotions регулировали с помощью следующего расширенного параметра vCenter:

По умолчанию он равен 2, что означает, что из 16 слотов хоста на каждую vMotion будет тратиться пара слотов, а суммарно будет возможно сделать 8 миграций одновременно. Если поставить это значение в 4, то, соответственно, будет выполняться 4 одновременных миграции (16/4=4).

Надо отметить, что настройка этого параметра не поддерживается со стороны VMware, поэтому не удивляйтесь, что если при его изменении у вас что-то пойдет не так.

Таким вот образом, под разными нагрузками на ВМ, проводили тестирование как восьми одновременных миграций:

Так и четырех:

Если миграции стоят в очереди, то для них отображается статус "Resources currently in use by other operation".

Результаты получились следующими (по оси Х изменяли объем оперативной памяти машин):

То есть восемь одновременных миграций с точки зрения эвакуации всех машин с хоста проигрывают рабочему процессу с четырьмя vMotion.

Аналогично возрастало и среднее время миграции:

Если говорить об использовании памяти, то видно что при 4 одновременных миграциях было передано на 10% меньше страниц памяти, что говорит о более эффективном ее использовании:

Для второго теста выбрали утилиту DVD Store, которую использовали для 2 типов соединений - 10 GbE и 100 GbE:

И здесь тоже результаты получились в пользу 4 одновременных миграций. Та же картина была и для 100 GbE-соединения:

Таким образом, получается, что при большом увеличении числа одновременных миграций vMotion на хосте, удельная производительность каждой такой миграции будет падать.

VMware просто сфокусировалась тут на более эффективном использовании канала для каждой из миграций, поэтому число одновременных vMotion имеет уже не такое влияние, как это было раньше. Поэтому данный параметр и не увеличивается в таблице максимумов от релиза к релизу VMware vSphere.

Релиз платформы VMware vSphere 6.5 в свое время (а это была осень 2016 года) оказался довольно удачным, поэтому до сих пор довольно большое количество пользователей используют его в производственной среде.

В июне прошлого года VMware объявила о продлении поддержки vSphere 6.7 в связи с пандемией, но кто ж знал, что все настолько поменяется, поэтому о продлении срока поддержки версии 6.5 сообщили только сейчас.

Теперь период general support period для vSphere 6.5 продлен на 11 месяцев до 15 октября 2022 года, что совпадает с аналогичным для vSphere 6.7. До этого момента достижение точки прекращения предоставления полной технической поддержки (EoGS, End of General Support) было намечено на 15 ноября 2021 года. Но окончание технического сопровождения (EoTG, End of Technical Guidance) не изменилось - оно наступит 15 ноября 2023 года.

У VMware нет планов продлевать период Extended Support для vSphere 6.5, поэтому тем, кому это важно, следует смигрировать хотя бы на vSphere 6.7, где расширенная поддержка будет действовать подольше.

Расширение поддержки для vSphere 6.5 будет с некоторыми ограничениями:

• Нужно будет использовать vCenter 6.7 для хостов ESXi 6.5, потому что там есть обновленный vSphere Client вместо старого Web Client.
• Для хостов на базе vCenter Server Appliance нужно будет обновиться на vCenter Server to 6.7 Update 3 (см. тут подробнее).
• vCenter Server for Windows нужно проапгрейдить до vCenter Server to 6.7 Patch 05 или более поздней версии (см. тут).
• Если вы не сможете обновить vCenter, то будет допустимо использовать vCenter 6.5, но как-то поддерживать работоспособность Flash-клиента (см. тут).

Аналогично продляются сроки оказания технической поддержки для VMware vSAN 6.5 и 6.6 до тех же дат и с теми же условиями, что и для vSphere: теперь окончание поддержки наступит 15 октября 2022 года, но EoTG также не изменится:

Ограничения расширения поддержки для vSAN остаются теми же, что и для VMware vSphere.

Все, кто хоть раз сталкивался с инфраструктурой виртуальных ПК VMware Horizon, знает, что в этом решении есть 3 способа развертывания виртуальных ПК для нужд различных типов пользователей. Делается это с помощью одного из следующих видов клонов:

• Full Clone - полная копия родительской виртуальной машины, абсолютно никак с ней не связанная и действующая как полноценная новая ВМ.
• Linked Clone - связанный клон виртуальной машины, создаваемый со стороны View Composer, который использует общее для всех клонов хранилище реплики на чтение, но имеет собственное хранилище для операций записи (дельта-диск или redo log). Память такой ВМ полностью независима от родительской ВМ, которая называется репликой (потому что она получается путем создания дубликата мастер-образа).
• Instant Clone - это мгновенный клон работающей виртуальной машины, то есть имеющий с ней не только общее хранилище на чтение, но и общую память, для которой также используется техника copy-on-write. То есть это больше похоже на контейнерную виртуализацию.

Давайте теперь посмотрим на все эти виды клонов в деталях:

Full Clone

Это самый простой и понятный случай. С точки зрения производительности это всегда будет лучший вариант, так как это обычная виртуальная машина. Функциональность тут та же, что и для обычных ВМ. Очевидно, что главный минус - это скорость развертывания такой ВМ под новых пользователей, ведь нужно физически скопировать данные ее виртуальных дисков.

Но есть и еще некоторый минус по сравнению со связанными и мгновенными клонами - это обновления. Так как полные клоны содержат свою копию ОС, то вам нужно обновлять каждую машину, а не только реплику/родительскую ВМ, как в случае с Linked и Instant Сlones.

В целом, тут рассказывать особо больше не о чем, параметры производительности полного клона можно взять за эталон по отношению к остальным видам.

Linked Clone

Связанные клоны появились довольно давно в решении VMware View (тогда Horizon еще не было). Их созданием занимался и продолжает заниматься компонент VMware View Composer, который управляет процессами, связанными с развертыванием пулов виртуальных десктопов.

Суть таких клонов заключается в создании реплики от мастер-образа виртуального ПК, который подготовлен к массовому развертыванию (настроена ОС и установлены приложения). Реплика является родителем для новых виртуальных десктопов в плане их общего хранилища на чтение. Все операции чтения, которые создают клоны, складываются в отдельные дельта-диски за счет технологии copy-on-write, позволяющей при записи операции I/O перемещать ее в отдельный файл отличий от родительского диска.

Это очень удобно - такие десктопы создаются очень быстро (нужно только создать дельта-диски), реплика не должна быть включена и активна (только ее хранилище), а хранилище очень сильно экономится, ведь общие данные (предустановленные приложения и ОС) хранятся только в одном экземпляре. Такая модель идеально подходит для временных ПК - например, для сотрудников кол-центров, которые используют какое-то приложение во время работы (например, CRM), но в остальное время десктоп оказывается не нужен.

В этом случае, в соответствии с политикой пула Linked Clone, виртуальный ПК можно уничтожить после отключения пользователя или оставить висеть до следующего логина, а уничтожать после операции Log off. Что еще тут важно - к такому десктопу можно прицепить persistent-диск, который будет сохранять данные пользователя даже при выключении десктопа.

Недостатки тоже очевидны: инфраструктура связанных клонов опирается на компонент View Composer и зависит от его надежности, а операции записи и чтения работают медленнее, так как при записи данных нужно потратить ресурсы на обработку механизма copy-on-write, а при чтении - найти откуда данные считать - из базового образа или из дельта-дисков пользователей.

Тут надо обязательно отметить, что начиная с VMware Horizon 8 (2006), связанные клоны помечены как Deprecated-функционал, то есть вскоре (а именно, в следующей мажорной версии Horizon) будет произведен переход на мгновенные клоны, о которых рассказано ниже.

Instant Clone

Функция мгновенного клонирования виртуальной машины (ранее известная как технология VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere. Что важно, она не зависит от централизованного сервера, а реализована прямо на уровне гипервизора VMware ESXi. Появилась эта возможность в vSphere 6.7 и до сих пор совершенствуется.

Работает мгновенное клонирование так: посредством Memory copy-on-write "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи и чтения собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Такой подход больше похож на контейнерную виртуализацию, где в рамках одной общей ОС работает несколько изолированных окружений - и это действительно так, со всеми его плюсами и минусами. Плюсом является экономия дискового пространства и памяти, а также скорость создания такого клона - он не просто быстрее создается, но и сразу включен и готов к использованию. Еще очевидным преимуществом является независимость технологии мгновенных клонов от сервисов View Composer, а значит в этом смысле надежность инфраструктуры таких ПК несколько выше.

Цикл включения нового десктопа для мгновенных клонов гораздо короче:

Минусы здесь те же самые, что и для связанных клонов, только добавляются ограничения по числу дочерних ВМ на одну родительскую, издержки на поддержание сложной системы работы с памятью (что влияет на безопасность и производительность), а также отсутствие поддержки некоторых функций.

Причина падения производительности ввода-вывода проста: у родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее.

Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.

Сейчас для связанных клонов недоступны следующие возможности:

• Кастомизация машин средствами Sysprep и Quickprep
• ОС Windows 8 и 8.1
• Функции Persona Management
• Тома Virtual Volumes (VVols)
• Нативные снапшоты на хранилищах через VAAI (vStorage APIs for Array Integration)
• Указание имен компьютеров ВМ вручную (это доступно для связанных клонов в пулах dedicated- или floating-)
• Политика питания Remote machine power policy (Always Powered On, Suspend, Power Off) для пула
• Привязка постоянных (Persistent) дисков

Несмотря на то, что персистентные диски не работают из коробки для связанных клонов, эту проблему можно решить с помощью продуктов Dynamic Environment Manger DEM , Microsoft FSLogix или VMware App Volumes Writable Volumes.

Отметим, что для мгновенных клонов (Instant clones) поддерживаются возможности TRIM и UNMAP для хранилищ vSAN.

Производительность клонов

У компании VMware есть прекрасный документ "Understanding Clones in VMware vSphere 7", где описываются результаты тестирования производительности всех трех типов клонов. Очень интересный whitepaper, давайте взглянем на некоторые выводы в нем содержащиеся.

Первое - это скорость развертывания клонов и тестирование производительности под большой нагрузкой ввода-вывода:

Очевидно, что связанные и мгновенные клоны создаются намного быстрее полных ввиду своей природы. Мгновенные создаются несколько дольше связанных из-за того, что первым нужно время не только на настройку операций copy-on-write с диском, но и с памятью.

А вот правая часть картинки показывает нам, насколько падает производительность подсистемы ввода-вывода при тяжелых нагрузках - для связанных клонов больше, чем в три раза, а для мгновенных - аж в четыре (Hammer DB создает нагрузку еще и на память, которую должен обслуживать механизм мгновенных клонов).

Второй не менее интересный тест - с помощью методики SPECjbb. Тут брали не машины с хранилищем 450 ГБ и тяжелой нагрузкой по вводу-выводу, как в прошлом тесте, а легковесные машины с 16 ГБ диска и нагрузку делали на CPU и память. Результат получился таким:

Первый важный вывод - самое большое время на развертывание связанные и мгновенные клоны тратят в самом начале, уступая для маленьких машин полным клонам, но потом полные клоны долго завершают копирование данных виртуальных дисков.

Второй полезный инсайт - с точки зрения отработки запросов к CPU и памяти (а именно это и меряет SPECjbb) все три типа клонов ведут себя одинаково в пределах статистической погрешности в 5%.

Следующая картинка - влияние на родительскую ВМ. Очевидно, что для полных клонов влияния никакого нет, а вот для связанных и, тем более, мгновенных клонов влияние большое:

И, опять-таки, для памяти и CPU связанных и мгновенных клонов такого влияния практически нет.

Следующая картинка - развертывание полного клона по сети на другой хост ESXi. Для мгновенных клонов такая возможность отсутствует, а для связанных требуется общее хранилище. Мы тут видим, как сильно увеличивается время развертывания полного клона по сети:

При увеличении числа виртуальных машин совокупная производительность по вводу-выводу растет вот так:

При увеличении числа клонов картина для CPU/памяти вполне ожидаемая:

С точки зрения CPU все три вида клонов будут работать одинаково, а вот с точки зрения памяти - мгновенные клоны будут немного помедленнее, так как некоторое количество ресурсов тратится на обслуживание работы механизма работы с памятью.

Что касается времени развертывания разного количества для трех типов клонов, тут тоже все понятно: полные клоны растут линейно, остальные - несущественно.

Итоги

Давайте сведем теперь в простую таблицу все преимущества и недостатки полных, связанных и мгновенных клонов, чтобы это могло помочь вам выбрать нужную схему использования виртуальных ПК:

Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu
• Quick Boot on Lenovo

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:

Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых функций мы упоминали возможность Enhanced Data Durability, позволяющую еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Как знают администраторы vSAN, этот продукт обеспечивает высокую степень защиты данных от сбоев, в том числе встроенным механизмом избыточности, регулируемым политикой FTT (Failures to tolerate).

Однако при отказе одного или нескольких хостов ESXi в кластере vSAN может произойти ситуация, когда дисковый объект есть на одном из хостов, но только в одном экземпляре. Такая ситуация опасна тем, что если произойдет второй сбой, затрагивающий этот объект - данные могут быть безвозвратно утеряны.

Кстати, при переводе хоста в плановый режим обслуживания такая ситуация тоже может возникнуть - но в vSAN этот момент учитывался и раньше, и на время обслуживания все операции записи сохранялись до момента возвращения хоста в строй, после чего происходило накатывание операций, случившихся за это время:

Теперь же такой механизм появился и для внештатных ситуаций:

При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные дискового объекта с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище (durability component), чтобы обеспечить надежность данных, записываемых во время сбоя.

По умолчанию в случае сбоя кластер vSAN ждет 60 минут до начала восстановления дискового объекта на другом хранилище хоста ESXi для обеспечения политики FTT. Это связано с тем, что кластер не начинает емкие по ресурсам операции для сбоев, которые могут оказаться временными. Регулируется это настройкой Object Repair Timer (она же настройка vsan.clomrepairdelay в Advanced Settings, подробнее об этом тут):

Если в этот момент случится еще одна авария, которая затронет единственно выжившую копию данных, то виртуальная машина остановится, но возможность восстановить данные будет - как только хост с последней копией данных восстановится, на них накатятся сохраненные инкрементальные операции записи. Это позволит получить состояние виртуальной машины без потери всех последних операций записи.

Надо сказать, что операции по созданию durability component имеют приоритет над стандартными операциями vSAN, такими как синхронизация дисковых объектов, поэтому это происходит очень быстро, чтобы сразу начать записывать дельта-writes. Операции записи в durability component будут продолжаться (он будет в состоянии active), пока синхронизация дискового объекта с его репликой не завершится удачно (либо на восстановившемся хосте, либо на новом, после операции rebuild). После этого durability component для дискового объекта будет удален.

Еще стоит отметить, что если хост с durability component откажет, то новый хост возьмет на себя его функции и создаст свой durability component (число таких операций не ограничено). Также полезно то, что защита данных с помощью durability component работает и для дисковых объектов с FTT=2 или выше - главное, чтобы у вас было для всех этих операций свободное дисковое пространство в кластере.

Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.

Давайте посмотрим, что именно там нового:

1. Увеличение iSCSI Path Limit

Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.

2. Поддержка RDM для RHEL HA

Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.

3. Улучшения снапшотов VMFS SESparse

При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.

4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)

В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.

5. Улучшения производительности для томов VMFS

Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.

6. Улучшения работы с NFS-хранилищами

Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.

7. Поддержка High Performance Plugin FastPath для Fabric Devices

Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.

8. HPP - дефолтный плагин для vSAN

Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).

9. Улучшения VOMA

Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.

10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints

В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.

11. Создание Config vVol больше, чем на 4 ГБ

Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.

12. Улучшения правил SPBM Multiple Snapshot

Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.

13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

14. Маппинг CNS PV на vVol

В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.